Cream of the Crop 1/Cream of the Crop 1.iso/UTILITY/CT43C.ARJ/CT43C.DOC

Text File | 1992-07-09 | 17KB | 355 lines

Program:    Cache Test
Version:    4.3c
Author:     George Spafford
Date:       July 9, 1992

Summary:

This program is designed to help a user evaluate the impacts
of a cache, or the changes to an existing cache, on a drive's
performance.

Furthermore, with users' increasingly using caches during a
variety of tasks, it is important to find the optimal cache
settings given the task at hand.  Whereas a word processor
might make heavy usage of sequential files, a database
might make heavy usage of random access files.  With this
in mind, the memory requirements, sectors cached, write
delays and so forth have many possible variations.

By default, Cache Test creates a 10,000 record sequential file
using 32 byte records and then a 10,000 record random access file
that again uses 32 byte record lengths.  Note, even if the default is
changed, any sample string length will be increased by two bytes by
the addition of a CR/LF.  You may want to compensate accordingly if
you wish to be exact in your measurements.  The sample record size
indicator displays the TRUE sample string size.

This program uses BIOS to do all of its reads and writes,
so any hardware or software cache should be able to get
some good "hits."  In attempt to flush caches during the
test, files are frequently opened and closed.

All of the times that this program writes are the result of
subtracting the beginning time from the ending time.  Nothing
fancy, so the values are relatively accurate.  Note, if you do
some math to compute access times per record, you will run into
the age old problem of significant digits.  This program only accounts
for one decimal location (0.1).  As such, if you try to take the
timings out to 1/100th of a second, the resulting error factor can be
quite high, relatively speaking that is.

Remember, if an outcome is in doubt, use a larger sample size!  That is
to say, increase the number of bytes that are written to the disk.  The
other alternative is to increase the number of sample passes.  You'll
notice that results begin to stabilize with file sizes of 5000 records,
32 bytes, and 5 passes.


A few definitions:

      "ButterFly Test"     The middle record is read and then a
                           record is alternatingly and read in each
                           direction from the middle.  Say you have
                           a 100 record file, the read order would
                           be 50,49,51,48,52,47,53 . . . and so on.

      "CR/LF"              Carriage Return and Line Feed.  Decimal 13
                           and 10 respectively (CHR$(13),CHR$(10)).  These
                           two characters are used as "end of record"
                           delimiters.  As such, they are included in the
                           byte count when a record is written.  If the
                           sample string is 10 bytes, these two additional
                           bytes are added to the end resulting in a total
                           of 12 bytes.  Bear this in mind if you want exact
                           values.

      "Crescendo Read"     Records are read alternatingly in from the end of
                           the file and the beginning file.  This is to say,
                           record 1, 10000, 2, 9999, 3, 9998, 4, 9997 etc.
                           Okay, Okay ... so my definition of Crescendo is
                           backwards... They didn't spell the Macintosh
                           correctly either.

      "Random Read/Write"  Random functions generate independent random
                           reads and writes.

      "Read-by-1"          A random access file's records are being accessed
                           one at a time.

      "Stepping-by-10"     A random access file's records are being accessed
                           on every 10th record.

      "Write-by-10"        A random access file's records are being updated
                           on every 10th record.

      "Overall"            This is the total time of all tests AND file
                           deletes.  So, it might not reflect the sum
                           of all tests exactly, but it should be very
                           close.

      I just wanted to make those meanings a little clearer.

      ******************************************************************

          Usage of this program is:

          CT  </D:d><F:bbb></N:nnn></S></R></B></?>

            CT by itself will test the active drive that it is on with
            the default record length of 32 bytes and 10,000 records.

        Explanation of switches:

        /D:d    This specifies "d" as the drive to be tested.

        /F:b    This specifies the number of fixed bytes per record.
                It must be between 1 and 32,765.  The default is 32 bytes.
                Use this with the /N:n switch to enhance your testing.
                (Because of CR/LF usage in the file structure, the logical
                limit for a user input is 32,765 and not the allowable
                32,767)

        /L:f    This is where you want your summary screen to be logged to.
                "f" can be a device or a file name.
                To go to the printer, a user might have:   /L:prn or /L:lpt2
                To go to a file, a user might have /L:ct.log.  If you log
                the data to a file, by default it is appended to the file if
                the file already exists.  If you want to create the log file
                fresh each time, use the /C switch also.

        /N:n    This specifies the number of test records.
                Note, the only limitation here is the available space
                on your test drive.  You can also go as small as
                you want, but you will reach a point where your test
                will lose its validity.
                The default value, if this switch is not used, is
                10,000 records.

        /P:ppp  This specifies the number of test passes.  In other words,
                the number of times that the test will repeat.  If this
                option is > 1 then when the passes have all completed,
                a Summary screen appears with average sequential, random
                and total times.  If there is only one pass, then the
                summary screen will not be displayed

        /B      Test both sequential and random access records.
        /C      Creates log files rather than appending data if the
                log file already exists.  This switch has no effect if
                the data is going to a device rather than a file.
        /R      Test random access records only.
        /S      Test sequential access records only.
        /W      Wait after each screen (pause).
        /X      Exclude run-time screen counters.


Suggestions:

You might want to set up a batch file that purges your cache
before CT is run.  This will allow the cache to have a little
fairer test, as opposed to starting out partially full.
Also, if you are interested in the actual hits on your cache, most
cache programs (PC-CACHE and NCACHE for sure) have status switches
that allow you to see the results from the cache's point of view.

The test file is written in the root directory of the target drive.
The file name is TEST$$CT.SPD.  If the critter appears, don't panic!
It probably didn't get deleted because of an interrupted test.

While it was never the intention of Cache Test to allow cross-machine
comparisons, I have decided to allow the counters to be disabled using
the /X switch.  On my system, an identical test with the counters
disabled was 42% faster than with the counters enabled.   If you want
to actually test the drive/cache subsystem without the video bottleneck,
use this switch.

HISTORY:

      v4.3c 07/09/92 pm

            Heck ... I can't win for losing.  I have spent several hours now
            debugging the variable overflow problem.  I believe that they
            have all been eliminated now.

            To say "sorry," you can have VT 1.1 also if you choose to register
            (or are already registered to) Cache Test - this just applies to
            people registering 4.3 or who are already registered now.


      v4.3b 07/09/92 am

            Ooops, I switched to explicit variable typing and ran
            into a problem when file sizes exceeded the limit of an
            integer variable (32,767) and the program bombed.  It's all
            set now.

      v4.3  07/06/92

            All screens can now be logged to a file or device.  This
            logging no longer requires that the pass count (/P:) be
            greater than 1.
            Every second data screen (excluding the final summary) has
            a form feed added to it to prevent printing across paper
            perforations when logging to a printer.
            The summary screen now displays the command line that was used.

         ** Due to the volume of mail that I am receiving, I am forced to
            stop responding to every piece of mail unless you have questions.
            I'm really sorry for that one folks, but it is seriously taking
            time away from me when I could otherwise be coding.

      V4.2  01/10/92

            Using the /L: switch, a user can now specify where he/she
            would like the summary screen to go (nice idea Jim).
            Also did a little house cleaning on the program in general.
            Happy New Year everyone.  I would like to thank three people
            especially for all of their tolerance and helpful suggestions:
            Tim Aright of Queued Access, Wayne Keeter of Wayne's World,
            and Jonathan Fisk.

      V4.1  11/13/91

            Well Owen, I thought about it.  The screen counters can
            now be disabled using the /X switch on the command line.
            Note, there are many variables that affect cache performance.
            It was never my intention to test cache performance across
            machines.  BUT, it is a good idea to allow the user the
            ability to decide for his/her self as to whether they want
            to or not.  If you disable the counters, there can be some
            long pauses - especially for the Random Read/Write test - so
            be patient.  CT now has the extremes - a lot of counters or
            none at all ;-)

      V4.0  10/29/91

            Whew... This one has quite a few updates:

            1.  COLOR (makes things a lot easier to read).
            2.  Tracking of timer ticks has been tightened down.
            3.  Created the ability to perform a number of tests
                and then present a summary screen with averages
                using the /P:ppp switch.
            4.  /W switch added for pausing after screens.


      V3.5  9/03/91

            In response to Mike Focke's request for counters in the
            crescendo and butterfly tests, I have again enabled them.
            And Mike, thanks for the suggestions ;-)

      V3.1  8/26/91

            The timing routine is now based on the presence of 18.2
            clock ticks per one second.  The 100ths decimal location is
            still weak, but improved.

      V3.0  7/10/91

            Well, I accessed the BIOS segment for clock ticks to create
            the decimal level counters.  The second decimal place is
            weak in terms of its accuracy, but I decided to leave it in.
            For those of you worried about significant digits, the
            algorithm used for this uses 18 clock ticks to generate one
            second of time.

            The test records are now 32 bytes total.

            Output screen formatting is improved.

            If the program is invoked without any parameters, it executes
            on the active drive with a 10,000 record test made up of 32
            bytes.  All user input now occurs on the command line through
            the use of switches.

      V2.6  5/24/91

            I honestly did not intend another update so soon.  It was
            pointed out to me that the file structure that I had been
            using was variable.  As such, it made ratio comparisons
            somewhat difficult.  Now, the default fixed record length
            is 32 bytes (the test record count is still 10,000).  The
            user can specify the record length by using the /F:bbbbb
            switch.  "bbbbb" must be between 0 and 32,765.   Since the
            values are now fixed, a user can do a little math (remember
            that subject folks??) and discern the records per second and
            so forth.  Do note, that two bytes are added to the test string
            in the files (CR/LF to be exact) that is why the maximum byte
            size that a user can specify is 32,765 and not the 32,767 legal
            default limit.

      V2.5  5/22/91

            1.  An actual test file byte size field has been added.
                This should allow users to track the actual sizes of
                the test records being written.
            2.  Some users suggested that truly random reads and writes
                should be added.  This serves to get away from any form
                of sequentialized data.
            3.  Again, more cosmetic touchups.

      V2.0  5/16/91

            Due to some users having limited drive space, switches
            were added to allow for different size tests to
            occur.  I was somewhat hesitant to do this because it
            negated the ability to call results "standard," but
            what really is standard?

            Switches were also added to allow users to select
            what tests they want to run.  For now, all that can
            be specified is whether or not to run all tests,
            sequential tests only, or random tests only.

            The ButterFly test was also added in an attempt to
            give look-ahead caches a hard time.  Some of the
            caches that use a FIFO method of purging will have a
            heck of a time with this one.

            Added timers/cleared up timers for the sequential and
            overall tests.  Also speaking of timers, to avoid
            slowing down some routines, I have removed some of
            the video effects that were for the user's benefit
            only.

            Special thanks to Jonathan Fisk for all of his
            suggestions and debugging efforts.

            Special thanks also go out to Tim Akright, the sysop
            of Queued Access for all of his support.


      V1.0  5/10/91

            Well, I released it.  That pretty well sums it up.


        I hope this program helps you evaluate some of your problems
        or even makes some solutions/benefits clear.  This program is
        released as shareware.  Its price is $5 for each concurrently
        used copy.  If you have any suggestions or comments, I'd REALLY
        like to hear those too.

                Sincerely,

                George Spafford
                3001 LakeShore Drive, #329
                St. Joseph, MI 49085

        Data:  [phone]  Queued Access BBS 14.4Kb USR Dual HST
                               Sysop:  Tim Akright

        And now for the unpleasantries:

        Code CopyRight:  1992 - George Spafford

        CT IS DISTRIBUTED AS IS.  THE AUTHOR (GEORGE SPAFFORD) MAKES NO
        WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED
        TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE,
        WITH RESPECT TO THIS SOFTWARE AND DOCUMENTATION. IN NO EVENT SHALL
        THE AUTHOR BE LIABLE FOR ANY DAMAGES, INCLUDING LOST PROFITS, LOST
        SAVINGS, OR ANY OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
        OUT OF THE USE OF OR THE INABILITY TO USE THIS PROGRAM.
        ----------------------------------------------------------------